Macintosh WATCHER

Strategies for Maximizing WATCHERís Value

As you work through this book, youíll learn how to access and use WATCHERís features. Youíll find out how to create a list of devices that you want WATCHER to monitor. Youíll also learn how to define different types of notifications for WATCHER to send if devices fail.

This chapter, however, is intended to provide you with some strategies for implementing WATCHER features. For example, youíll learn how to setup the devices so that you can easily pinpoint failures. These strategies will help you get the most value from WATCHER.

This chapter assumes that youíre familiar with the infrastructure of your network and that you understand the relationships among its various devices.

Monitoring Strategies

Before WATCHER starts monitoring devices, you must perform the following setup and configuration tasks:

ï add the devices you want to monitor to the Main Test List;

ï create notifications and the default followup;

ï attach notifications to devices; and

ï define key devices.

The devices that you add to the Main Test List should include any device thatís part of the chain of devices into or out of the network server. You can determine which devices belong to this chain by using a third-party application designed to trace network devices.

Typically, the trace application identifies three or four common devices. The following illustration shows a network in which three devices, a router, and a Web server are common to most paths into and out of the server:

Because each device is dependent on the next device, the failure of one device causes all the devices that come after it to fail as well. However, you can define key devices so that only the notification for the failed device is sent; notifications for its dependent devices are suppressed.

The following table identifies the key device assignments for the network shown in the previous illustration if youíre monitoring from Point B:

Under this scenario, if the router fails, its notification is sent. Notifications for Device 1, Device 2, and Device 3 are suppressed. Similarly, if Device 2 fails, its notification is sent and the notification for Device 3 is suppressed.

The key assignments are reversed if youíre monitoring from Point A:

Alerting Strategies

If the server goes down, a notification is sent based on conditions that youíve defined. However, what happens if the person who receives the notification is unavailable and canít respond to it?

To avoid this problem, you should include with your notifications some form of escalation strategy. For example, if no one responds to the notification within five minutes, then WATCHER sends another notification to someone else.

In WATCHER, the set of escalation notifications is referred to as the "default followup". You can define only one default followup, but it may include several notifications.